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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In :e: the Application of: William Flanagan et al 
Fil*d: 10/30/00 
Serial No.; 09/702,049 
Ex *minen Meinecke Diaz, Susanna M. 
Gr:aip Art Unit; 3623 

Fo System and Method for Automated, Iterative 
D€ irelopment Negotiations 
Dc <zket No: ET00-007CIP 

RESPONSE TO OFFICIAL ACTION 

D rector of the US Patent and Trademark Office 
POBox 1450 

A exandria, VA, 22313-1450 
D:ar Sir: 

Ei tidosed please find a supplemental response for the above-identified application in 
re sponse to the official action mailed 12/16/02. 



C liirtificate of Facsimile Transmission 

I j lereby certify that this document is being sent to the United States Patent Office by 
fa simile transmission on the date shown below. 

Date: August 20, 2003 



T -l 508 653^8143 
Re marks: 

In telephone discussions with the Examiner, it was requested that applicants clarify the 
a{ -paratus claims to indicate that the software executes on a processor. It was also 
re guested that applicants' clarify how applicants' invention differs from redlining and 
fr» >m the Kennedy reference cited. 

A :»plicants have agreed to Examiner's amendments to the apparatus claims to include a 
pi t>cessor to clarify and more distinctly point out and claim applicant's invention, but 
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n >t to overcome any prior art. The amendments made incorporate terms of description 
ai kd not of limitation 

A pplicants respectfully submit that the distinction between applicants' invention and 

r< dlining was addressed in applicants' parent applications. In the excerpts below, 

aj iplicants have indicated in bold face type in brackets where the cited portions of the 

p. Lrent specification are found in the current pending application (bold face in brackets 

ft ir current pending application ]. In the parent cases it was noted that 

For the phrase "automated negotiations engine" support is found in the 
specification at Page 60, lines 9-20, Page 61 lines 1-18, and Page 62, lines 1-18, 
[Page 66, lines 5-18, and Page 67, lines 1-16] where the processing steps of the 
automated negotiations engine are described. On Page 62, lines 11-16 [Page 67, 
lines 9-14], for example, state: 

Whether or not a concluding document is requested, the system 
automatically displays the changes so they can be easily seen and the 
present invention also checks to see whether a state change is needed at 
Step 21 2-16. If a state change is needed it is initiated at step 212-20. 
Depending on the community, the participants, and the transactions 
involved/ state changes could be as simple as payment authorizations sent 
electronically or as complex as multi-step processes desired by the 
participants. [Emphasis added] 

Abo, as noted in the specification at page 52, lines 14-18 and Page 53, lines 1-4 
{Page 57, lines 3-121: 

Next; in Figure 1L, network functions 207 of the present invention 
are shown. As mentioned above, most of the functions of multivariate 
negotiations engine 212 are actually implemented as part of Webserver 
software 210s . As data is sent to and from the Internet 04 by Webserver 
210W, Webserver software 210s interprets the TCP-IP protocol and 
transfers the contents to multivariate negotiations engine 212's 
Webserver and dynamic HTML functions 207-02 . In one embodiment, 
these functions cause dynamic HTML text to be created to implement and 
communicate with the other functions of the present invention. Those 
skilled in the art will appreciate that Java, Java scripting , XML, or any of 
a number of other languages could also be used for such communications. 
[Emphasis added] 

Thus, it can be seen from these and other portions of the specification, amending 
the claims to clarify that the negotiations engine is an automated negotiations 
engine has ample support in the specification as filed. It is implemented in 
computer software which is executed as part of Webserver software in the 
example referenced above. 
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Support for the phrase "analyzing terms, the analysis of terms comprising 
understanding their purpose, formatting the terms according to the purpose and 
placing them into user supplied context for use by a user" is found in the 
specification at Page 86, fines 1 5-19 and Page 87, lines 1-4 [Page 92, lines 16-18 
and Page 93, lines 1-6): 

For example, and still in Figure 5a, if a buyer participant 08 wishes 
to place a proposed order, the browser encrypts it at the browser's secure 
socket layer and webserver 210s decrypts the proposed order upon receipt 
at multivariate negotiations engine 02's site. Webserver 210s next a nalyzes 
the proposed order to understand it and formats into a request sent to 
database functions 222 . In addition to basic read and write functions, 
d atabase functions 222 shown in Fijgfure 5a, include operation s such as 
search, analyze, compare, report sort and relate (betwee n databases.) 
Formatting can be as simple as "user usemame" etc. A request such as 
"find user=username, return catalog" might be sent through IP firewall 
203f . [Emphasis added] 

User supplied context, which can be defined as a number of interrelated variable 
terms or items as noted in the specification at page 44, lines 19 and 20 [Page 48, 
lines 18-19 and Page 49, line 1 1, for example, indudes rules supplied by a 
sponsor, terms and conditions supplied by a seller, terms supplied by a buyer, 
etc., as shown in more detail below. 



An example of "user supplied context" is found in the specification at Page 65, 

lines 7 -12 [Page 70, lines 8-13], where the user is a buyer 

Now referring to Figure 15b, a typical proposal form for a buyer is 
shown. As seen here, the buyer identifies himself, his title, his company, 
and the company's location at lines 332-342. At lines 344-350 information 
about the buyer's designated freight forwarder is given. At line 350, 
document presentation terms are specified, as well as at line 352, 354, 358 
and so on, the detailed terms of the buyer's preferences for shipment 
[Emphasis added] 



Another example of "User supplied context" is found in the specification at 
page 45, lines 6-9 [Page 49, lines 7-10], where the user is a sponsor 

The sponsoring standards body establishes the community, 
proposes initial standards, sets the rules for negotiations, encourages and 
monitors negotiations, and concludes with a finally agreed upon set of 
standards, with each step of each negotiation that occurred along the way 
archived. [Emphasis added] 

Still another example of 'User supplied context" is seen in the specification at 
Page 49, lines 6-15 [Page 53, lines 11-17 and Page 54, lines 1-3], where the user is 
a seller: 
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Now turning to Figure lg, the present invention can be viewed as a 
series of interrelated processes as shown here. For a commercial 
community, there are seller processes, sponsor processes and buyer 
processes. Remote authoring 50, is a seller process which enables a 
registered seller in the community to create a seller Website within the 
community on which to include the seller's marketing and product 
information, along with pricing- terms, service offerin gs and so on. 
Information generated or created in this remote a uthoring process 50 is 
automatically integrated with the community database s and listings. 
Promotion and brand identifying actions (such as registering the Web 
page with search engines) are taken automatically on behalf of the seller 
as well. [Emphasis added ] 

Support for the phrases "recognizing any changes in the terms" and "'the 
automated negotiations engine indicating any changes" is found in the 
specification at Page 62, lines 1-3 [Page 66 lines 17-18 and Page 67line Ij: 

Multivariate ne gotiations engine 212 keeps trac k of each set of 
changes and can display them so that the changes proposed at each step of 
the negotiations are clearly and accurately recorded. [Emphasis added] 

US Patent No. 5,692,206, to Shirley et al (Shirley) was brought to applicants' 
attention as potentially rendering obvious applicants' invention's negotiations 
engine and indication of changes as part of a negotiations process. Applicants 
respectfully disagree. Shirley describes a document generation system which 
helps a user create a document for use in a negotiation, but it does not automate 
the negotiations process. (See Col 2, lines 11-45 in which it is clear that Shirley 
describes a system of libraries of standard terms from which a user can manually 
select one or more provisions.) Shirley discloses a "negotiating database" which 
is not an automated negotiations engine but simply a file or database for holding 
"one or more corporate suggestions 442 and one or more user notes 444/' Col 5, 
lines 49-51. In Col. 7, lines 14-40, it is dear that Shirley describes a system in 
which the user selects from a library of standard contract provisions those 
provisions the user wants to incorporate into his or her contract proposal. This is 
not a negotiations process, but simply a way to create a proposed contract 
document that one party might send to another by regular mail, fax, or e-mail. It 
teaches away from applicants' invention by focusing on word-processing-like 
document assembly techniques, not on negotiation processes. 

Finally, Shirley does not teach, disclose or render obvious an automated 
negotiations engine for indicating charges in the proposed terms. Instead, it 
teaches away from this as well, by teaching a redlining feature in which "the user 
creates one or more redline documents 218/' Col. 7, lines 61-62- The user selects 
two text versions of a document for comparison and, as disclosed at Col. 11, lines 
46-58: 

If, at the decision block 702, the user selects a redline function, the 
system controller 102 branches to a process block 718. At the process block 
718, the system controller 102 activates the redline unit 120. The redline 

4 
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unit 120 prompts the user to select to [sic] files to be compared. A redline 
comparison is typically done between a current document and either a 
corresponding standard document or a previous revision of the same 
document. The redline unit 120 generates a new file that specifies the 
differences between the two files selected by the user, without affecting 
the selected files. The redline unit 120 may be implemented, for example 
[sic] a redlining program such as CompareRite. [Emphasis added] 



Redlining, as described above, is a text comparison of two documents. Changes 
in the text are underlined, usually in red, or "redlined." The program that does 
the redlining does not analyze the changes in any way, or prompt actions as a 
result of them. 

Applicants' invention, by contrast, during the negotiations process, provides an 
automated negotiations engine that analyzes terms by understanding their 
purpose, formats them according to their purpose, and places them in a user 
supplied context for use by a user. The automated negotiations engine also 
recognizes changes in the terms and indicates what has changed. It can also 
prompt for additional information as a result of a change. For example, if a 
shipping term such as Ex Works, has changed to Deliver Duty Free, the 
automated negotiations engine system of applicants' invention knows what 
additional information to request from the user, such as the name of the user' s 
freight forwarder, and will format requests for that information. 

Support for this is found in applicants specification at Page 86, lines 15-19 and 
Page 87, lines 1-4 [Page 92, lines 16-18 and Page 93, lines 1-6], as referenced 
above, as well as in Figure 15 Ol and Figure 15 C-2. 



A >plicants respectfully submit that the above darificattons apply to the present 
aj [plication as weft. Unlike redlining, applicants' invention analyzes terms, the analysis 
of terms comprising understanding their purpose, formatting the terms according to the 
pi cpose and placing them into user supplied context for use by a user. As shown above, 
us supplied context refers to the fact that users of applicants' invention can supply the 
cc ntext for one or more negotiations. In the illustrative examples shown in the 
sp deification and the drawings, user supplied context has included, among other 
th ngs; community rules; standards; buyer's terms; seller's terms; sponsor, seller, 
ar J buyer processes; application programming interfaces; templates; administrative 
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in : ormation; pnxiuct information; procedures; text, image and sound files; deciding 
ei tities, and numerous other items, according to the kind of negotiation and the kinds 
oi users involved. Non-commercial users may supply very different types of user 
st pplied context as shown in the parent application at Page 61, lines 2-6 [Page 65, line 
H and Page 66, lines 1-4J. 

Ir the discussion with the Examiner, applicants were also asked to clarify the 

di ;;tinctions between applicants' invention and that which is claimed and disclosed in 

V : . Patent. No. 6,055,519 issued to Kennedy et al on April 25, 2000, entitled 

") ramewoik for Negotiation and Tracking of Sale of Goods ("Kennedy"). 

A pplicants respectfully submit that Kennedy does not disclose, claim, nor render 
d i vious an : automated negotiations system for processing negotiations. The Kennedy 
S3 stem does not process negotiations, but stores data representing the current state of a 
m igotiation, to allow the user to monitor the state of a negotiation. This is stated in the 
A bstract as follows: 

A computer implemented system and process are provided for negotiation and 
tracking of sale of goods. In this system and process, a negotiation engin e (16) 
operates to store data representing a current state (18) of a negotiation between a 
seller and buyer. The negotiation engine (16) stores the data within a framework 
for representing aspects of the negotiation between the seller and buyer. The 
framework includes a request object, a promise object and an acceptance object 
that can store a current de^cription of a contract, The framework also includes a 
set of one or more delivery deals determined, by the contract. Each delivery deal 
can have a delivery request object, a delivery promise object, and a delivery 
acceptance object that can store associated item deals and time periods for 
delivery of item deals. Each item deal can have an item request object, an item 
promise object, and an item acceptance object that can store individual sales- 
order line-items. The ne gotiation engine (16) thereby allows a use r to monitor the 
current state of the negotiation . . . 
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11 tis is also dear from the following text in the description of the Kennedy patent at 
G>1. 4, lines 4-17: 

Buyer 14 can have a negotiation client 22 that communicates with 
negotiation engine 16 across a network communication layer. Negotiation dient 
22 can comprise a software application executed by a computer system and 
allows buyer 14 to query current state 18 . Negotiation client 22 can be used to 
communicate requests and acceptances from buyer 14 to seller 12, and 
negotiation engine 16 can be used to communicate promises from seller 12 to 
buyer 14. The request promise and acceptance information ran alio he 
communicated through other means such as bv fax, phone, etc. According to the 
present invention, ne gotiation engine 16 provides a framew ork for maintaining 
current state 18 to reduce or eliminate any confusion about the status of the 
negotiation and relevant terms. [Emphasis added] 

Ez sentially, Kennedy stores data objects of limited types which represent a request, a 
pi omise or an acceptance. Since the data stored in the objects could have been 
cc mmunicated by fax or telephone, it is dear that Kennedy is simply storing the data, 
n< it processing a negotiation. The Kennedy "negotiation engine" stores these objects, 
ai d as will be seen below, uses the time stamps associated with each to determine the 
st ntus of the "negotiation". 



T3 tis state monitoring is described at Col. 5, lines 50-57 as follows: 

In the present invention, the state that a negotiation is in can be 
determined, for example, from the relative values of four time stamps: the date 
that the most recent request was issued, the date that the most recent promise 
was offered, the date that the most recent acceptance was made, and the most 
recent date that the request was queued. If there is only a request issued date, 
then the negotiation can be identified as being in state 32. [Emphasis added). 



K ^nnedy also states at Col. 4,lines 26-35: 

In the embodiment of FIG. 2, the negotiation can move through twelve 
states. There are essentially five kinds of changes that can be made to cause state 
transitions: the buyer can issue a new request (R), the seller can offer a new 
promise (P), the buyer can queue a request (Q), the buyer can accept a promise 
(A), or the buyer can delete or withdraw a request (D). All five changes are not 
necessarily applicable to each state . In particular, the buyer can delete or 

7 
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withdraw a request until it is accepted, but once accepted, the request can no 
longer be withdrawn by the buyer. [Emphasis added] 

Ti lis makes it clear that the system itself is only reporting on state transitions. It is 

tr icking what the buyer and seller have done in the past^ as the description expressly 

st sites at Col 6, lines 19-25: 

...the negotiation process can thus be tracked between buyer and seller in 
constrained environments by providing a framework for progressing through 
the state diagram of FIG. 2 while also storing the current state of and relevant 
data for the negotiation [Emphasis added] 

T ie limitations on a buyer and seller are illustrated by the following sample, from coL 4, 
lii les 48-54: 

From state 34, the buyer can do one of four things. The buyer can delete or 
withdraw the request which moves the negotiation back to state 30. The buyer 
can issue a new request, moving the negotiation to state 36. The buyer can queue 
the existing request, moving the negotiation to state 38, and the buyer can accept 
the promise, moving the negotiation to state 40. 

B f rther, Kennedy d oes not recognize the users as negotiators or recognize one of them 
at a deciding entity. 



Ir stead, Kennedy is simply moni toring and tracking the state of some very limi ted 

cc mmunications between a buyer and a seller. Even while describing some of its 

a< ! vantages, this is made apparent at CoL 6, lines 43-50: 

The present invention provides numerous advantages over conventional 
negotiation processes. First, the exact state of the negotiation is detailed in such a 
way that automated and semi-automated decision systems (such as planning 
systems, order fulfillment systems, purchasing systems, supply chain 
management systems, etc.) can work against the alternate state transitions, and 
deal with the changes in states over time. [Emphasis added.] 

T! lis, and similar sections of the specification make it readily apparent that this is a 
m :>nitoring and reporting system, not a negotiations system. 
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Ir addition, the system appears to be primarily designed for the use of planners (not 

n* igotiators) for order or demand management systems in either a buyer' s or seller's 

oi ganization as seen at Col. 9, lines 57-64: 

The Request, Delivery Request, and Item Request structures together 
model and provide a framework for requests from one site to another. The 
Promise, Delivery Promise, and Item Promise structures together model and 
provide a framework for the supplying (promising) site's commitment back to 
the requesting site. These structures together implement what is traditionally 
called "Order Management" or "Demand Management" Simplified variations of 
those structures are often called "orders." [Emphasis added] 

A v part of this, the Kennedy specification describes some specific formats and types of 
rt quest, promise and acceptance objects, containing pre-defined fields for data such as 
qi iiantity, due date, price, etc. If a buyer and seller use these pre-defined object formats 
ai id fields, the system can track their communications and feed the specific data into 
oi der management or demand management systems. Alternately, as stated above, their 
c< inrespondence by telephone or fax can be stored in these formats and thus tracked. 



Ti re specification states at col. 14, lines 39-41 that 'The basic information provided is the 

st fcte of the negotiation for each order (e.g. whether the order is Requested, Promised, or 

A xepted)." and, at Col. 14, lines 42-52 that: 

Additional information can be provided which is termed "problems". An 
example problem is an order whose Promise does not match the Request. 
Another example is an order that is Promised but not Accepted (part of the 
"basic information" mentioned above). Another example is an order that is 
not yet promised and is planned but the planned delivery is later than 
requested. These pieces of information are critical for a human or automated 
planner to juggle capacities and modify plans in a way that optimizes 
performance of the supply chain. [Emphasis added) 
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In furtherance of the above statement, the specification describes, at Col. 14, Unes 66-65 

aid Col. 15, lines 1-3: 

. . .types of problems that can be identified. It covers the meaning of each 
problem, the data used to identify the problem, and where possible the 
resolution methods by which a human or automate d planner could try to 
eliminate or reduce the severity of the problem. fEmphasis added] 



A n example of one of the types of problems which the invention, can identify is found at 

Crt. 15, lines 10-21: 

A "Request Not Planned" problem indicates that the item request was 
issued after the item promise was offered-and-the delivery plan* has not been 
planned to satisfy the item request: either there is no delivery plan", or the 

delivery plan' is for the older item promise. This Problem will not occur if the 
delivery request has an infinite "due" Date, the item request is for a zero 

quantity", or the item promise was offered after the item request was issued (or 
last modified). To resolve this Problem , "to** Pliminate or zero out the item 
request (unlikely), offer' a Promise and switch the "delive ry plan" to satisfy the 
promise, or create and /or replan the 'delivery plan" to meet the item 
request .FEmphasis added] 

A ?. this example, and the others show, this problem identification is done, for the most 
p. Lrt, after the fact, when the negotiation has presumably completed and primarily for 
tf e benefit of the planner or demand management system, not the negotiators. 



If lihe planner uses one of the recommended solutions to "fix" the problem, the system 

vi oil update the problem data, and reflect that, as described in the specification as well, 

ai Col. 18, lines 1-13: 

As any change occurs to the data of a Request, Promise, Acceptance, 
Delivery Request, Delivery Promise, Delivery Acceptance, Item Request, Item 
Promise, or Item Acceptance, the invention reanalyzes the data and updates the 
identified problems. Data changes cause some problems to be eliminated and 
potentially others to be created. The human planner c an see these updates in a 
character-based user interface or a graphical user interface. The automated 
planner would see these updates by notification of which problems are 
eliminated and which (if any) are created. For mis purpose, the invention has a 



in 
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database of problems and an interface to an automated platmer which 
rammanicates the stream of created and de stroyed problems. [Emphasis added] 

K, rnnedy does state, at Col. 18, lines 14-28 that in connection with such problems, : 

Changes can be made at any point in a negotiation, including after the 
negotiation is traditionally viewed as •complete" (Acceptance is made). 
After acceptance, the seller and buyer both have the ability to reopen 
negotiations. The seller is allowed to change the Promise to reopen 
negotiations. The buyer is allowed to change the Request to reopen 
negotiations. (The invention allows this, although some applications of the 
invention may not In a manufacturing operation, machine breakages and 
strikes really require that promises be broken. Likewise, a supplier can 
rarely be rigid with their customers' requests.) When such changes occur, 
request-promise-acceptance problem calculatio ns can be rerun. However, a 
locking mechanism can be used to prevent request and promise data from 
changing and instead reporting a warning if any entity attempts to change 
such data. [Emphasis added.] 

It is clear both from the specification and the claims, that this identification of problem 
c< editions is used to, as Kennedy's Claim 14 puts it "pinpoint mistakes in the 
m rgotiation." 



K :mnedy does not disclose or claim or render obvious a system for processing 

n- gotiations, but a system tor monitoring state transitions amongst a set of narrowly 

d nfined objects. 

K rinnedy does not recognize the users as negotiators nor does it recognize one of them 
aj a deciding entity. It appears that one primary user of the system described in 
K cxinedy is a human or automated planner and that actual negotiators are simply being 
nc onitored by a system in which they can store data or in which data is stored about 
ti air actions, which may have taken place by telephone or fax, and not through direct 
u ne of the monitoring system of Kennedy (see Col. 4, lines 12-15: The request, promise 
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a* d acceptance information can also be communicated through other means such as by 
fa^ phone, etc/'.) 

A ;>plicants respectfully submit that Kennedy is not a negotiations system at all, but as 
it ?.ays, a framework for a tracking or monitoring system for a very limited set of 
tr. unsaction types related to order and demand management for the sale of goods. 
K unnedy does not disclose, claim, nor render obvious applicants' invention. 

A :*plicants respectfully submit that all bases for objection and rejection have been 
o^ ercome and that Claims 2-98 are in condition for allowance. Reconsideration of all 
tih e claims is requested. Allowance of Claims 2-98 at an early date is solicited. 

A :»plicants ' Attorney respectfully requests that if she can be of any further assistance in 
pi itting all the claims in condition for allowance that she be reached by telephone at 
5C ti-653-8143 or by cellular phone at 508-308-2109 in order to discuss the application 
w th the Examiner, so that any new objections or rejections may be addressed. 

D, Lte: August 20, 2003 

Respectfully Submitted, 

Maureen Stretch 
Reg. No. 29,447 

O ist No. 27,443 26 Charjes Street 

T« 1. 50S-653-8143 Natick, MA 01760 
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